dimos/stream/twitch/votes.py, line 666-670 (link)

Per-voter deduplication not implemented in plurality/majority/weighted_recent modes

The PR description advertises "Per-voter de-duplication" as a general feature, but only _tally_runoff performs any deduplication (and only in its runoff phase). _tally_plurality, _tally_majority, and _tally_weighted_recent all count every entry in the votes list, allowing a single Twitch user to spam votes and skew results.

For example, in plurality mode a single user can send "forward" 50 times in the window and dominate the outcome.

If per-voter deduplication is desired across all modes, the de-duplication should happen before calling the tally functions, e.g.:

def _deduplicate(votes: list[tuple[str, float, str]]) -> list[tuple[str, float, str]]:
    """Keep only the last vote per voter."""
    seen: dict[str, tuple[str, float, str]] = {}
    for v in votes:
        seen[v[2]] = v  # overwrite with latest
    return list(seen.values())

Then call votes = _deduplicate(votes) before tallying.

dimos/stream/twitch/module.py, line 297-298 (link)

is_mod detection relies only on badges, missing the IRC mod tag

The Twitch IRC protocol provides a dedicated mod tag (value "1") that is more authoritative for moderator status than the moderator badge entry. Badge display can be inconsistent (e.g., if the badges tag is absent for some reason). Twitchio also exposes message.author.is_mod directly.

dimos/robot/unitree/go2/blueprints/smart/unitree_go2_twitch.py, line 79-97 (link)

Blocking sleep loop in _on_choice without synchronization

_on_choice is called from a subscription callback and blocks the calling thread for command_duration seconds (default 1 second) using a while/sleep loop. If two TwitchChoice events arrive close together (e.g., if the vote loop fires slightly late), two concurrent invocations of _on_choice can execute simultaneously, resulting in interleaved Twist publishes from two goroutines — confusing robot behavior.

Consider adding a lock, or cancelling the current command before starting a new one:

def __init__(self, **kwargs):
    super().__init__(**kwargs)
    self._cmd_lock = threading.Lock()

def _on_choice(self, choice: TwitchChoice) -> None:
    with self._cmd_lock:
        ...

The same pattern exists in examples/twitch_plays/run.py at ChoiceToCmdVel._on_choice (lines 950–968).

dimos/stream/twitch/votes.py, line 753-756 (link)

Auto-generated filter pattern doesn't gate vote counting

The auto-generated pattern (requiring the bot prefix !) is applied to filtered_messages only. _on_message_received is called for every message via _handle_message, so a user typing bare "forward" (no prefix) will still have their vote counted even though the message is blocked from filtered_messages.

This creates a discrepancy: messages silently get voted on without any feedback to downstream filtered_messages subscribers. Consider documenting this behaviour clearly, or routing _on_message_received to only run after the filter check if prefix-gating of votes is the intended design.

dimos/stream/twitch/module.py, line 332-336 (link)

inject_message skips _on_message_received, breaking vote testing

inject_message calls raw_messages.publish and _publish_if_matched but does not call self._on_message_received(msg). Compare with _handle_message (lines 302–306), which calls all three.

TwitchVotes overrides _on_message_received to record votes. This means calling inject_message on a TwitchVotes instance will publish to streams but no vote is recorded — silently breaking the primary stated testing method described in the README. The fix is to add self._on_message_received(msg) as the last line of inject_message.